This patent document and the patent disclosure contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as they appear in the Patent and Trademark Office patent file or records but otherwise reserves all copyright rights whatsoever.
This invention relates to computer operating systems. More particularly, this invention relates to events and the synchronization of a program's execution to those events.
An understanding of certain computer operating system concepts is necessary to understand the invention. UNIX.TM. is taken as an example. (UNIX.TM. is described more fully in the Portable Operating System Interface, Part I (International Standard ISO/IEC 9945-1: 1990, IEEE Std 1003.1-1990, 1990) ("Posix"). Posix is incorporated herein by reference.)
In UNIX, a "process" or "thread of control" is the dynamic, run-time embodiment of a program. The program typically resides in a static state on a storage medium such as disk or ROM, while the process is loaded into memory and is executing. UNIX is a multitasking operating system: Many processes and threads can execute essentially simultaneously.
Many operating systems of the art and, particularly, all flavors of UNIX provide a process with the ability to synchronize its execution with the occurrence of some specific event.
Such an event might include the completion of a synchronous I/O operation, the asynchronous arrival of data from a remote client machine, the unlocking of a mutex, the exit of a thread or subprocess, etc. Each event traditionally has a corresponding notification mechanism through which a process can detect the actual occurrence of the event. Currently, however, there is no desirable mechanism to allow a process or thread running on such an operating system to synchronize on more than one event notification at the same time.
As an example of the problem, a process or thread might desire to suspend execution until either a resource (e.g., a specified mutex) becomes free and can then be acquired or until a request was received from a remote client, indicating that an I/O packet needs to be examined. Given that either of these events can occur first, that either occurrence must awaken the process or thread and that the process or thread can synchronize on only one of the events, then on which of these events should the process or thread block?
There are several standard approaches that partially solve this common problem: complete operating system support, timeouts, signals, selection, asynchronous I/O and threads. Each partial solution relies upon whatever functionality the operating system underlying the user program happens to provide. Each partial solution is examined in turn below.